作者
Kylo
投资经理
Zonff Partners
Twitter: @kylohanks_eth
ETH 2.0 的 Merge 阶段近在咫尺，官方预计约在 9 月 15 日左右实现 POW 到 POS 的转换。此次 POS 转换与以往公链分叉所用的方式不同，并没有采用在特定区块高度分叉的方式，而是规定了 TTD 并设置 “难度炸弹”。TTD 全称为 Total Terminal Difficulty，即以往所有区块难度的总和。当全网积累的挖矿难度值达到 TTD 时，ETH 主网会启动 “难度炸弹”。“难度炸弹” 是进行以太坊难度调整的后门函数。以太坊的 POW 出块时间并没有固定，而是根据全网算力大小对挖矿难度进行动态调整，通过这种方式把区块时间固定在一个大致的范围。难度炸弹的部署则是通过后门函数将挖矿难度调整到一个极大的值，使得没有矿工可以在该挖矿难度下生产区块，从而推动着矿工放弃 POW。POW - POS 的转换并没有设置一个固定的区块高度，而是规定 TTD 作为 Merge 发生的时刻，部分原因其实在于防止有人刻意破坏 Merge 的进程。社区关于 ETH 分叉之争主要集中在 POW 与 POS 谁更加符合区块链自身的定义以及特性，即 POS 是否违背了区块链去中心化的精神以及是否具有抗审查性。但无论争论的结果如何，目前已经有多方势力包括矿工群体、交易所群体以及 ETH 大户在为各自的利益用脚投票。可能的延期利空则是因为 8 月的 Goerli 测试网合并时出现了一些问题，这些问题并没有影响测试网的合并。但对于 Merge 这种会影响以太坊未来发展的重要事件，小问题可能会使主网合并推迟数月。此外，合并的推迟也相当于为 POW 分叉创造了时间，增加了整个体系的混乱度。若最后真的实现了 POS/POW 分叉，可能存在的情况包括：- ETH POW 链分叉链缺少预言机，DeFi 失效；
- 分叉链中由中心化机构发行的资产，如 WBTC 资产等没有了实际价值支撑；
- ETH POW 链缺少 RPC 接口，用户无法与 ETH POW 进行链上交互；
- AMM DEX 的定价不依赖于预言机，因此 Uniswap POW 可以独立运行，但是由于大多数 DeFi 币没有价值，因此抢先将所有 AltcoinPOW 换成 ETH POW 将能获得最大收益；
- 由于缺少连接 ETH POW 的 RPC 接口，钓鱼攻击的频率会增加。黑客可能利用用户在 RPC 上授权，ID 为 1 的 TX，在 POS 链上展开重放攻击，骗取用户 ETH 2.0 主网的资产；
- 交易所是最大的受益者，ETHPOW 的变现必须通过交易所实现，这意味着交易所只要支持 ETHPOW 的买卖就可以获取交易手续费；
- ETH POW 生态的虚无也给了各个项目方可乘之机，例如在 ETH POW 链上发行以 ETHPOW 为抵押品的稳定币；
普通交易者在整个过程中可做的事情其实并不多，最重要的还是注意不要被钓鱼攻击和重放攻击。ETH 2.0 自提出到开始实行经历了一次大改，最初 ETH 2.0 的设计（以下均称 Sharding 1.0）是实现状态分片。状态分片可以简单理解为将以太坊主网拆成多条子链，并将其命名为 Shard1、Shard2 ……，每条 Shard 都有以太坊主网的全部功能，拥有独立的状态并且独立处理各自的交易，最后利用信标链将所有的子链统筹起来，也就实现了状态分片。但在 2020 年随着 Rollup 潜力的凸显，以太坊便改变了其实现状态分片的路线图，而将数据分片（以下称为 Sharding 2.0）作为 ETH 2.0 的最终目标。数据分片类似于模块化区块链，即将以太坊分成多个数据分片，每个数据分片连接一个或多个 Rollup，Rollup 作为执行层而以太坊则成为数据层与共识层的底层。因此目前 Sharding 2.0 的整个路线图大致分为三部分：Merge、Proto-Danksharding 和 Danksharding。Merge 预计发生于 9 月 15 日，而 Proto-Danksharding（EIP-4844）预计在两年内完成，Danksharding 的实现更是在未来的 3-4 年。实现 Danksharding 后以太坊的 TPS 有望达到互联网级别，从而奠定了区块链应用的未来。Harmony 的分片模式与 ETH 的 Sharding 1.0 版本极为类似，若 ETH 2.0 没有改变路线图，则未来以太坊主网关于 Sharding 的形态机制将与 Harmony 大体一致。Harmony 利用信标链统筹分片链的状态，不同的分片可以理解为同质化子链，子链内部的交易由管理子链的验证者进行验证。每个分片在出块后都需要将分片区块的区块头存储在信标链对应位置的区块中，这样使得信标链区块可以存储所有分片的状态信息。除了统筹分片链的状态外，信标链还需要执行的功能包括提供随机数用于随机轮换各个分片的验证者和区块提议者、记录每个分片的 BLS 聚合签名以及验证者的状态。信标链确立区块提议者以及与各个区块对应的委员会的方式是通过随机数实现的。区块提议者将负责提议区块，负责该分片的委员会在分片内部达成 FBFT 共识，并在确认后将达成的共识上传信标链（FBFT 共识指的是挑选一个领导者节点，领导者节点收集其他验证者的签名，因此通讯复杂度为 O(n)，方便快速达成共识）。
制图：Zonff Partners
来源：https://harmony.one/whitepaper.pdf
区块提议者在其所属的 Slot 中提议一个区块，并将该区块头信息向其他验证者传播；
验证者在收到消息后确认该区块头，并附上自己的签名，表示接受该区块提议者提议区块；
这些签名汇集到区块提议者那里，计算合成为一个 BLS 聚合签名；
区块提议者将 BLS 签名发送给验证者，当 BLS 签名中包含超过 2/3 的验证者权重时，验证者将对区块内的交易进行验证，验证结束后附上自己的签名，表示交易验证完成，并将签名发送给区块提议者；
区块提议者收集 BLS 签名，在 BLS 签名超过 2/3 的权重时确认该区块，并将该区块以及所有的 BLS 签名广播给所有的验证者，分片链上的 Slot 成功出块；
分片链上的 Slot 出块时，该区块头信息以及生成该区块时各个验证者的 BLS 聚合签名将会被记录在信标链对应的 Slot 中。同时其他分片也会收到该分片的区块头信息并记录在区块内，方便跨片交易的验证；
在所有的分片都出块后，对应位置的信标区块将收集所有的区块头信息、BLS 聚合签名以及所有验证者的状态并将这些信息打包成信标链区块。但这个过程中其实存在着分片链出块与信标链出块的协同性问题。由于分片链过多，短时间里信标链可能没有办法收集全所有的分片链头信息，从而出现漏块的情况。为解决这个方面的问题，Harmony 从两个方面给出了解决方法：一是用 FBFT 共识取代 PBFT 快速达成分片区块内的共识；二是利用高性能节点快速协同信标链区块和分片链区块的信息。Harmony 的问题其实是所有分片链都会遇到的问题，针对这个问题 Near 和 ETH 2.0 分别给出了自己的答案。尽管 Harmony 与 ETH 2.0 的 Sharding 1.0 版本在结构上有些相似，但其仍然具有不同于 ETH 2.0 的特点，具体包括：- 验证者质押的币会随机分配到不同的分片，这意味着发动攻击的人没有办法把币集中在某一个分片上；
- 验证者质押获得的奖励并不与质押的币的数量线性相关，而是具有凹性，即边际质押收益递减；
- 新入驻的节点可以通过 Hashlink 连接每个 Epoch 的 Checkpoint 以实现快速状态同步；
- 跨分片交易时可以绕过信标链直接进行分片链之间的交易；
Near 一直以来以分片作为该公链的特色，但直到目前为止 Near 还没有实现像 Harmony 那样的状态分片。Near 在架构上也与 Harmony 这些以信标链为协调枢纽的分片结构不同。Near 的分片集中在一个区块内，即将一整个区块做分割，分成不同的 Chunk。而 Chunk 其实也就可以被认为是一个分片。- 2021年第四季度实现 Simple Nightshade，将 Near 的区块空间分成四个 Chunk;
- 2022年第一、二季度在 Near 生态引入 Chunk-Only-Producer；
- 2022年第三季度通过 Nightshade 真正实现分片；
- 2022年第四季度实现动态分片，即根据容量需求动态调整 Chunks 的大小；
上述概念可能会让人有一些疑惑，其实直到 2022 年第三季度 Near 的 Nightshade 开始实行前，Near 都没有做到状态分片，状态分片的实行是逐渐推行的。Simple Nightshade 阶段只是把区块空间分片，但是交易的确定与验证与其他 Layer1 POS 公链没有太大差别，验证者同时处理所有的交易。接着在 2022 年第二季度，Near 引入了新的角色 - “Chunk-Only-Producer”，其本质上也是验证者，只不过作用范围局限在单个分片内，用于专门验证每个 Chunk 内的交易。该阶段里 Near 生态里总共有两大类验证者，第一类是可以出块的高性能验证者，负责整合所有的 Chunk 块并汇总成整区块以及跟踪所有分片状态并进行交易验证；第二类就是局限在分片内的 Chunk-Only-Producer，负责分片内 Chunk 的出块以及 Chunk 内交易的验证。第二类验证者对于节点性能的要求并不高，因此 Near 公链在 Chunk-Only-Producer 层面可以做到一定程度的去中心化，但仍然需要高性能的第二类验证者负责大区块的生成。第三阶段 Near 将实行 Nightshade，此时 Near 才真正实现了状态分片。
制图：Zonff Partners
来源：https://near.org/downloads/Nightshade.pdf
状态分片的实现意味着每个分片可以被看作是一条 “链”，该分片上的交易由负责该分片的 Chunk-Only-Producer 进行验证。为更近一步降低验证者节点的性能要求，Near 使用纠删码技术对 Chunk 的数据进行处理，而没有选择对 Chunk 内的所有数据进行广播。直接广播 Chunk 的所有数据可能会使性能较低的出块节点出现丢包的现象，而通过纠删码技术，验证节点只需接受 Chunk 的碎片信息即可，从而降低了节点的性能负担。纠删码是一种对于数据的冗余处理办法，将一整块数据处理成 n 份，当需要进行数据还原时只需要其中任意的 f 份即可。在某个 Chunk 数据的广播过程中，Chunk 数据被冗余处理，每个验证节点随机获取一份纠删码。当大多数的验证节点收到来自所有分片内 Chunk 数据的纠删码时，这些节点会发动共识投票，汇总各个节点手中的 Chunk 纠删码数据段，恢复原来的 Chunk，并按照分片顺序对所有的 Chunk 进行排列，确立 Near 的主区块并附上聚合签名。Near 为解决验证者网络中心化问题使用的纠删码技术目前已经被多种协议或者公链所使用，ETH 2.0 的 Danksharding 也同样使用纠删码技术以达到去中心化验证以及可拓展的效果。Merge 代表着信标链与目前以太坊主网的合并，以太坊网络将 “无感” 转换为 POS 共识机制。“无感” 主要针对的是用户，但对于矿工以及验证者节点而言，他们仍需要为 POS 转换做一些客户端层面的改变。
制图：Zonff Partners
来源：https://ethresear.ch/t/eth1-eth2-client-relationship/7248
类似于模块化区块链将执行与共识分离一样，Merge 之后以太坊客户端也会做到执行与共识的分离。POW 阶段的以太坊客户端被称为 ETH 1.0，其包含挖矿、POW 共识、交易验证、内存交易池等多个功能。但当共识机制转向 POS 后，ETH 1.0 Client 中关于挖矿以及 POW 共识的部分将全部被废除，剩下的部分作为执行客户端继续运行在以太坊网络中。共识层则是由共识客户端负责，也称为 ETH 2.0 Client，运行在信标链节点上，主要负责达成 POS 共识。共识客户端与执行客户端合并起来共同组成了 Merge 后的以太坊客户端，两者之间的连接是通过 API 实现的，并通过 JWT 私钥进行验证。共识客户端与执行客户端可以做到分离，验证者可以只运行执行客户端并把共识客户端托管在信标节点上，也可以选择在同一台机器上同时运行执行客户端和共识客户端。如下表所示，运行客户端并不要很高的性能，消费级别电脑即可。| Client | CPU Usage | Minimum RAM Usage | Sync Time |
| Lighthouse | Moderate | 2 GB | Moderate (normal sync) Instant with checkpoint sync |
| Nimbus | Low | 0.75 GB | Moderate (normal sync) Instant with checkpoint sync |
| Prysm | Moderate | 2 GB | Moderate |
| Teku | Moderate | 4 GB | Slow (normal sync) Instant with checkpoint sync |
| Client | Type | CPU Usage | Minimum RAM Usage | Sync Time |
| Geth | Full | Moderate | 4 GB | Moderate |
| Besu | Full | Moderate | 16 GB | Moderate |
| Nethermind | Full | Moderate | 16 GB | Fast |
| Infura* | Light | Low | --- | None |
| Pocket* | Light | Low | --- | None |
制表：Zonff Partners
来源：https://docs.rocketpool.net/guides/node/eth-clients.html#execution-clients
图片来源：ethos.dev
POW 出块是通过求解哈希难题实现的，在全网算力动态变化的情况下，每个区块出块时间也会动态变化。但由于 POS 是指定出块者，每个区块的时间间隔是固定的。Merge 之后以太坊会以 6.4 分钟为一个 Epoch，共 32 个 Slot，因此每个 Slot 为 12s，理想情况下每个 Slot 都应该有一个区块。信标节点通过 RANDAO 和 VDF 确立每个 Slot 的验证者委员会以及区块提议者，一个 Epoch 需要挑选 32 个提议者和 32 个验证者委员会。每个 Slot 都应该有一个区块，如果没有则说明区块提议者没有尽到自己的义务，将会被罚没部分 ETH。根据泊松分布，在考虑可能存在区块丢块的情况，区块的生成时间平均下来约为 13s。对于如何理解 RANDAO 和 VDF，以下举个简单的例子，RANDAO 是一种生成随机数的方式，假设班级里有 10 个同学，老师想随机挑选一名学生给其发放奖励。老师给出的挑选方法是所有的同学同时给出一个随机数，老师将得到的 10 个随机数加和，最后得到的数字对 10 求余，剩下的数字就是应该挑选的同学。但是从上述 RANDAO 的运行过程中其实可以发现一个问题。如果某个同学作弊，后于 9 个同学给出随机数，那么其就可以根据 9 个同学给出的随机数信息，挑选一个最有利于自己的数字，使最后的结果指向自己。因此 RANDAO 的有效运行是需要引入防作弊机制的，即需要用一定的方式保证所有人同时给出答案。VDF 也就派上了用场。VDF 全称为可验证延迟函数，该函数的重要特征在于得到结果的计算过程无法并行计算，即无法加速。但得到结果后，验证该结果的计算量却又非常小。VDF 是通过哈希函数实现的，哈希函数计算慢验证快的特性也跟 VDF 的性质一致。VDF 的具体实现过程比较复杂但有一种简单的理解方式：F(x) = (((x)^2)^2)^2………^2上述函数的 () 并非简单算术中表示的 ()，而是某个复杂函数。计算 F(x) 的值只能串行运算多次。在单次计算时间确定的情况下，计算该函数所需要的时间是固定的，这也就因此解决了 RANDAO 可能存在的作弊问题。研究特定的 VDF 算法，维持 VDF 计算时间的稳定性对于 ETH 2.0 网络的稳定非常重要。Ethereum Foundation 曾与 Filecoin 合作研发 ASIC 化的 VDF 算法。稳定后的 ASIC 算法可以将 VDF 计算时间限制在 102 分钟。3.3 Gasper FFG 与 LMD GHOSTGasper FFG 在 ETH 2.0 中主要实现区块的最终确定性，而 LMD GHOST 则是通过分叉选择规则，选择某个区块接入当前的链。这两个机制都是以投票的形式达成共识。每个验证者在验证区块时需要向信标链提供三个信息：确认区块内交易的签名、Gasper FFG 投票以及 LMD GHOST 投票。上传确认各个验证者签名的原因在于，当验证者提供错误证明后，上传信标链的签名将成为罚没该验证者 ETH 的证据。Gasper FFG 投票是每个 Epoch 内所有的验证者必须参与的投票，一个 Epoch 只投一次，作用是确立该 Epoch 以及上一个 Epoch 的 Checkpoint。Checkpoint 指每个 Epoch 内的第一个区块。由于可能存在区块信息传输不及时的情况，对于不同的验证者而言其观察到的每个 Epoch 内的第一个区块可能并不一样。因此 Gasper FFG 投票的本质就是统一这种可能存在的信息差，把每个 Epoch 的 Checkpoint 定下来。在当前的 Epoch 结束时，若有超过 2/3 权重的验证者为该 Epoch 的某个区块背书，认为其为该 Epoch 的 Checkpoint 并投票给上个 Epoch 的 Checkpoint 时，上个 Epoch 的区块被认为达到最终确定，而该 Epoch 的区块则被定义为 Justification 的状态，可译为待最终确定。因此在以太坊实现 Merge 之后其区块最终确定的时间反而变长了，至少为 6.4 分钟，最多为 12.8 分钟。在 Merge 之前，以太坊区块的最终确定性是通过最长链原则实现的，6 个区块即可确定最长链，因此最终确定时间只需要约 1 分钟。但实际上 POW 的最终确定和 POS 的最终确定性是有一定差异的。虽然 POS 达到最终确定性的时间较长，其一旦达成便不可回滚。而对于 POW 而言，其达成最终确定的区块永远都有回滚的风险。LMD GHOST 又称分叉选择规则，每个 Slot 内的验证者都需要根据权重选择当前 Slot 连接主链的区块，LMD GHOST 投票也是为了解决区块确认过程中存在的信息差的问题。举个简单的例子，Slot 1 位置生成了区块 A，Slot 2 位置生成了区块 B，但由于信息传递不及时，小部分 Slot 2 的验证者并没有收到区块 B 生成的任何信息，因此错把区块 A 当作 Slot 2 对应位置的区块，此时由于区块 B 获取了最多的票数，其将在 Slot 2 的位置与主链连接。以太坊主网转向 POS 后每年 ETH 的产量将大幅度降低，而且由于 EIP-1559 在不断销毁 ETH，ETH 有望由通胀转为通缩。但在 Merge 后以太坊主网的 GAS 和 TPS 并没有很显著的变化。由于出块时间固定为 12s，相比于 POW 阶段 12-30s 的浮动出块时间而言，单位时间内可以容纳的交易增多，TPS 增加。TPS 的增加也使得以太坊主网没有那么拥堵，使得 Basegas Fee 略有下降，每笔交易更加便宜。总体而言 Merge 对于 ETH 流通量的影响远远大于其对 GAS 和 TPS 的影响。TPS 和 GAS 的革命性调整还得等到 Danksharding 的落地。Proto-Danksharding 也被称为 EIP-4844 提案，主要内容是向以太坊区块中引入 Blob 交易格式。EIP-4844 提案是为以太坊彻底实现 Danksharding 做出的准备，其并未将以太坊做到分片，验证者节点仍然需要下载并且验证所有的数据。目前阶段以太坊的区块大小是由 Gas 容量确定的，在 EIP-4844 实施后 Blob 的数量成为决定区块大小的另一个维度。Blob 是一种二元数据结构，大小约为 128 KB。以太坊区块对每个区块内可以容纳的 Blob 做出了限制，目标 Blob 数量为 8，最大为 16。因此每个区块将额外增加 1-2 MB 的存储空间。Blob 主要用于存储 Layer2 数据，在此之前其数据的存储是通过 Calldata 实现的，而一个区块内 Calldata 的容量只有约 10 KB 。这意味着在引入 Blob 后区块内可用于存储的空间将增加至少 100 倍。但由于单位空间内 Calldata 与 Blob 的信息密度不一样，虽然 Blob 空间比 Calldata 大 100 倍，但实际可以容纳的交易数量可能并不能达到 100 倍。Blob 数据较大，每个区块将引入至少 1 MB 的 Blob 数据，一个月将多出数 TB 的数据。为解决数据量快速增加的问题，每月产生的 Blob 数据将会离线存储。EIP-1559 是针对区块大小调整的提案，其对区块内可容纳的 Gas 量做出了调整，设置了目标 Gas 以及最大 Gas 量。当区块内的 Gas 量高于目标 Gas 时，每笔交易的基础 Gas 费将上调 12.5%，产生的基础 Gas 费将会被销毁（基础 Gas 费被销毁的原因在于防止矿工恶意发送垃圾交易拥堵 ETH 网络从而获取高额手续费）。EIP-4844 也为区块大小做出了调整，当 Blob 的数量超过 8 时，下一个区块的基础 Gas 费将升高，产生的基础 Gas 费也同样被销毁。EIP-1559 与 EIP-4844 的整合将为以太坊区块大小以及 Gas 费率引入更加动态的调整机制。
| Target | Max | Base Gas |
| Blob | 8 | 16 | Variable |
| Gas | 15m | 30m | Variable |
“中心化出块、去中心化验证” 是 V 神对于以太坊未来形态的构想，这种构想通过 PBS、Crlist 以及 DAS 则有机会变成现实。PBS 全称 “Proposer-Builder- Separation”，即构建区块时区块提议者与区块构建者的分离。其核心思想在于向系统中引入 Builder 角色（Builder 必须是高性能验证者），由 Proposer 提议区块，Builder 竞拍交易的排序权并计算区块头，Proposer 根据 Builder 的计算结果打包交易并将区块头写入区块完成出块。- ETH 2.0 面临的 MEV 问题：Proposer 既负责打包交易又负责交易的排序，可通过其特殊身份获取 MEV；
- 分片与信标链的同步问题：Sharding 1.0 的构想中，64 条分片链在 12s 的时间内出块并将验证后的区块头信息、签名、验证器的状态、交联等数据发送给信标链，由信标链打包出块。整个过程较为复杂可能会出现漏块的情况（交联即为 Crosslink，每个分片区块都要与信标链区块产生交联，方便跨分片通信）；
- 验证者子集分离的安全性问题：Sharding 1.0 的 64 个分片中的每个分片在一个 Epoch 的时间里被分成了 32 个 Slot，每个 Slot 都需要一个委员会进行投票验证。因此原本的验证者群体被分割成 (64+1) x 32 个验证者子集，每个验证者子集需要负责一个 Slot 内区块的生成与验证；
上文解释了 Harmony 对于信标链与分片链出块的协同性问题的解决方法，其核心想法在于利用 FBFT 快速达成共识以及高性能节点快速打包区块。这种解决方案的缺点在于不能解决抗审查问题、没有考虑 MEV、验证者网络仍然分离。Danksharding 解决协同性问题的方式也是通过中心化的方式，但却考虑了以上可能存在的问题。相比于 Sharding 1.0 每 12s 挑选 64+1 个 Proposer 和委员会，分别负责所有分片和信标链的出块以及区块验证，Danksharding 每 12s 只挑选 1 个 Proposer、1 个 Builder 和 1 个委员会。信标链和所有分片的区块都由 Proposer 提议，由一个 Builder 构建，由 1 个委员会验证。由于所有的出块信息最后都只汇集到 1 个 Proposer 手中，信标链和分片链的出块可以做到同步进行。此外原本 64+1 个委员会子集在 Danksharding 后被汇集成一个，验证者子集过于分散的问题可得到解决。Proposer 和 Builder 共同承担所有区块的构建任务，但是为了保证 Proposer 的去中心化，其不可处理高性能计算的问题。因此高性能计算的任务也就交给了 Builder。Builder 在整个系统中充当的角色是 “无情的计算机”，主要原因在于其不能筛选交易，只能对 Crlist 内的交易进行排序，并进行哈希计算。Proposer 在发布构建区块的竞拍任务时会发布 Crlist，该 Crlist 包含 Proposer 可见的所有的交易，Builder 在交易排序时必须将该 Crlist 的所有交易囊括在内，否则无法参与竞拍。由于 Proposer 是随机且去中心化的，而 Builder 只是排序打包机器，并不能对交易的筛选起任何作用，因此也就维持了交易的抗审查性。对于 MEV 的问题，通过使用 PBS，ETH 2.0 中的 MEV 流通路径可以归结为：交易者向 Builder 寻租 - Builder 竞拍排序权 - 市场化竞价下，Builder 可以获取的额外收益与拍卖成本基本持平，Builder 寻租收益接近于 0 - 收益由验证者网络获取。最后的 MEV 收益由全网验证者共享而不是流入个人钱包。这种解决方法也很契合 MEV 的本质。毕竟 MEV 是一个公共系统产生的额外收益，这部分公共收益更应该由维持网络运行的人共享。数据可用性抽样（DAS）是解决区块链状态爆炸的有效方法。状态爆炸指随着时间的积累以太坊主网积累的太多的交易数据以及账户历史余额数据，使得节点的负担过重，验证节点的进驻门槛升高，不利于验证者网络的拓展。而利用 DAS 技术，验证节点在同步以及验证区块数据时无需下载所有数据，只需要下载区块的部分冗余片段即可，需要进行区块重构时多个节点互相配合。但 DAS 在数据碎片重构时可能遇到一些问题。大区块的碎片化重构需要高性能的处理器，这与 DAS 低性能去中心化要求的初衷相违背。因此 DAS 需要一种不需要高性能节点的大区块重构算法。Danksharding 的 DAS 采用的方式是 RS 编码以及 KZG 多项式承诺。大区块数据利用 RS 先进行一维拓展，再利用 KZG 多项式承诺进行二维拓展。二维拓展多引入了一个维度，因此可以基于该维度对冗余数据进行分割，分成多个片区。当需要区块中的某一部分数据时，只需要挑选出该区块对应的片区，对该片区进行重构即可。也正是因为每个分区都可以做到单独重构，整个大区块的重构可以通过不同分区并行重构的模式进行，从而降低了重构数据对于节点的性能要求。由于 DAS 可以做到对区块数据的并行化处理，未来即使增加 Sharding 的数量也不会很显著的增加验证节点的性能负担，这部分负担可以通过增加验证者的数量来解决，但 Builder 的性能则需要进一步提升。Danksahrding 通过 PBS 实现以太坊的中心化出块，通过 DAS 实现去中心化的验证，让以太坊成为可拓展的数据可用性底层，使得以太坊未来可以容纳应用链 Rollup，智能合约平台 Rollup 等多种 Rollup。EIP-4844 中 Blob 交易格式的引入也将显著降低 Rollup 的成本。由此看来 Danksharding 实际上在为模块化区块链的未来下注。目前大多数公链的主流选择仍然是共识与执行层耦合，Danksharding 关于模块化区块链剑走偏锋的选择是否正确则有待时间的考验。文中提及项目，均不构成任何投资建议
对文章内容有任何建议，欢迎后台留下联系方式讨论
ETH Merge 后的投资机遇，敬请期待。
参考文章:
https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/
https://ethresear.ch/t/phase-one-and-done-eth2-as-a-data-availability-engine/5269
https://blog.ethereum.org/2020/03/27/sharding-consensus/
https://ethereum.org/en/upgrades/
https://ethresear.ch/t/questions-pertaining-to-danksharding-validation-committees/13230
https://ethresear.ch/t/rollup-as-a-service-opportunities-and-challenges/1305
招聘
投递邮箱：fane.fan@zonff.partners